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Beschreibung 

Verbindung von Teilnehmern in hybriden Komraunikationsnetzen 

5 ... 

In der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Ubermittlung von Informationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Iro Zuge der Konvergenz dieser bei- 
10 den Netztypen haben sich konvergente (Sprach-Daten-) Netze 
herausgebildet. Durch Zusararaenschluss dieser unterschiedli- 
chen Netztypen entstehen hybride Netze, in denen der Gegen- 
stand der vorliegenden Erfindung mit besonders sch6nen Vor- 
teilen zum Einsatz kommt. 

15 

Leitungsorientierte Netze - auch Sprachnetze oder Telephone 
netze genannt - sind auf die Ubermittlung von in der Fachwelt 
auch als Gesprach, Call oder Session bezeichneten kontinuier- 
lich stromenden (Sprach-) Informationen ausgelegt. Die Uber- 

20 mittlung der Informationen erfolgt hierbei ublicherweise mit 
hoher Dienstgute und Sicherheit. Beispielsweise ist fur Spra- 
che eine minimale - z.B. < 200 ms - Verzogerung (Delay) ohne 
Schwankungen der Verzogerungszeit (Delay- Jitter) wichtig, da 
Sprache bei Wiedergabe im Empfangsgerat einen kontinuierli- 

25 chen Inforrnationsf luss erfordert. Ein Informationsverlust 
kann deshalb nicht durch ein nochmaliges Ubermitteln der 
nicht iibermittelten Information ausgeglichen werden und fuhrt 
im Empfangsgerat ublicherweise zu ein em akustisch wahrnehmba- 
ren Knacksen. In der Fachwelt wird die Ubermittlung von Spra- 

30 che verallgemeinert auch als Echtzeit- (Ubermitt lungs-) Dienst 
bzw. als 'Realtime-Service' bezeichnet. 

Paketorientierte Netze - auch Datennetze genannt - sind auf 
die ubermittlung von in der Fachwelt auch als 'Datenpaket- 
35 strdme' oder 'Flow' bezeichneten Paketstromen ausgelegt. 

Hierbei muss Ublicherweise keine hone Dienstgute garantiert 
werden. Ohne garantierte Dienstgute erfolgt die Ubermittlung 
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der Datenpaketstrome z.B. mit zeitlich schwankenden Verzo- 
gerungen, da die einzelnen Datenpakete der Datenpaketstrome 
iiblicherweise in der Reihenfolge ihres Netzzugangs uberrnit- 
telt werden, d.h. die zeit lichen Verz8gerungen werden uraso 
5'- gra&er/ je mehr Pakete von einem Datennetz zu ubermitteln 

sind. In der Fachwelt wird die Ubermittlung von Daten deshalb 
auch als Obermittlungsdienst ohne Echtzeitbedingungen bzw. 
als 1 Non-Realtime-Service T bezeichnet. 

10 Die Pakete konnen beispielsweise je nach Art des paketorien- 
tierten Netzes als Internet-, X.25- oder Frame-Relay- Pakete, 
aber auch als ATM-Zellen ausgebildet sein. Sie werden zuwei- 
len auch als Nachrichten bezeichnet, v. a. dann, wenn eine 
Nachricht in einem Paket ubermittelt wird. 

15 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zum Einsatz kommenden Internet Protokolls IP zuwei- 
len auch IP-Netz genannt, wobei dieser Begriff grundsatzlich 
weit zu verstehen ist und alle Netze umfasst, in denen das IP 
20 Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 
unterschiedlicher Hersteller konzipiert. Es stellt eine 
herstellerunabhangige Transportplattf orm zur Verfugung. 

25 

Verbindungen sind Kommunikationsbeziehungen zwischen zumin- 
dest zwei Teilnehmern zum Zweck einer - zumeist gegenseiti- 
gen, d.h. bi-direktionalen - Inf ormationsiibermittlung. Der 
die Verbindung initiierende Teilnehmer wird iiblicherweise als 

30 1 A- Teilnehmer T bezeichnet. Ein durch eine Verbindung mit 

einem A-Teilnehmer in Verbindung gesetzter Teilnehmer heiflt 
•B-Teilnehmer 1 . In einem verbindungslosen Netz reprasentieren 
Verbindungen zumindest die auf logisch abstrakter Ebene ein- 
deutige Beziehung zwischen A- und B-Teilnehmer, d.h. entspre- 

35 chend dieser Sichtweise stellen z.B. die verbindungslosen 

Flows im Internet logisch abstrahierte Verbindungen dar (z.B. 
A-Teilnehmer = Browser und B-Teilnehmer = Web Server) . In 
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einem verbindungsorientierten Netz represent ieren Verbindun- 
gen zudem auf physikalischer Ebene eindeutige Wege durch das 
Netz, entlang denen die Informationen uberraittelt werden. 

5 Ira Zuge der Konvergenz von Sprach- und Datennetzen werden 
Sprachubermittlungsdienste und zunehmend .auch breitbandigere 
Dienste wie z.B. ttbermittlung von Bewegtbildinformationen 
ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Obermittlung der bisher ublicherweise leitungsorientiert 

10 ubermittelten Echtzeitdienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz genannt - paketorientiert, d.h. 
in Paketstromen. Diese werden auch Echtzeitpaketstrome ge- 
nannt. Die ttbermittlung von Sprachinf ormationen uber ein 
paketorientiertes IP Netz wird dabei auch mit 'VoIP 1 (Voice 

15 over IP) gekennzeichnet . 

In den internationalen Standardisierungsgremien IETF (Inter- 
net Engineering Task Force) und ITU (International Telecommu- 
nications Union) mehrere Architekturen fur Sprach- Daten-Netze 
20 beschrieben. Allen ist gemeinsara, dass die Call Control Ebene 
und die Resource Control Ebene funktional deutlich voneinan- 
der getrennt sind. 

Die Call Control Ebene umfasst dabei zumindest einen (optio- 
25 nalen) Call Controller , dem u.a. folgende Funktionen zugeord- 
net sind: 

- Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernaraen) auf Trans- 
portadressen (z.B. Internetadressen) . 

30 - Admission Control (optional) : Grundsatzliche Zulassig- 

keitsprufung, ob und in welchem Umfang (z.B. VoIP fahige) 
Einrichtungen das Kommunikat ions netz nutzen durfen. 

- Bandwidth Control (optional) : Verwaltung von Ubermitt- 
lungskapazitaten . 

35 - Zone Management: Registrierung von (z.B. VoIP fahigen) 

Einrichtungen und Bereitstellung obiger Funktionen fur al- 
le beim Call Controller registrierten Einrichtungen. 
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Optional konnen einem Call Controller zudem folgende Funktio- 
nen fallweise zugeordnet werden: 

- Call Control Signalling: Alle Signalisierungsnachrichten 
5 werden von zumindest einem Call Controller vermittelt, 

d.h. alle Einrichtungen schicken und erhalten Signalisie- 
rungsnachrichten nur uber den Call Controller. Ein direk- 
ter Austausch von Signalisierungsnachrichten zwischen den 
Einrichtungen ist untersagt. 
10 - Call Authorization: Zulassigkeitsprufung fur eingehende 
und ausgehende Calls. 

- Bandwidth Management: Steuerung der zulassigen Anzahl von 
Einrichtungen , die gleichzeitig das Komraunikationsnetz 
nutzen durfen. 

15 - Call Management: Verwaltung einer Liste bestehender Ge- 
sprache, urn z.B. ein Besetzzeichen erzeugen zu konnen, 
falls dies von der Einrichtung selbst nicht erzeugt werden 
kann . 

- Alias Address Modification: Ruckgabe einer modif izierten 
20 Alias Adresse, bspw. mit einer H. 225.0 Nachricht ACF (Ad- 
mission Confirmation) . Diese Adresse muss der Endpunkt bei 
Verbindungsaufbau verwenden. 

- Dialed Digit Translation: Ubersetzung der gewahlten Zif- 
fern in eine E.164 Telephonnummer oder eine Nummer aus ei- 

25 nem privaten Nummerierungs schema. 

Beispiele fiir Call Controller stellen der von der ITU in der 
H.323 Standard Familie vorgeschlagene 'Gatekeeper 1 oder der 
von der IETF vorgeschlagene ' SIP Proxy 1 dar. Wird ein groBe- 

30 res Kommunikationsnetz in mehrere Domanen - auch ' Zonen' 

genannt - gegliedert, kann in jeder Domane ein separater Call 
Controller vorgesehen werden. Eine Domane kann auch ohne 
einen Call Controller betrieben werden. Sind mehrere Call 
Controller in einer Domane vorgesehen, soli nur ein einziger 

35 von diesen aktiviert sein. Ein Call Controller ist aus logi- 
scher Sicht getrennt von den Einrichtungen zu sehen. Physika- 
lisch muss er jedoch nicht in einer separaten Call Controller 
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Einrichtung realisiert sein, sondern kann auch in jedem End- 
punkt einer Verbindung (beispielsweise ausgebildet als H.323 
oder SIP Endpunkt, Endgerat, Media Gateway, Multipoint 
Control Unit) oder auch einer primar zur programmgesteuerten 
5 Datenverarbeitung ausgebildeten Einrichtung (beispielsweise: 
Rechner, PC, Server) vorgesehen werden. Auch eine physika- 
lisch verteilte Realisierung ist moglich. 

Die Resource-Control-Ebene umfasst zumindest einen Resource- 
10 Controller, dem u.a. folgende Funktionen zugeordnet sind: 

- Capacity Control: Steuerung des dem Komraunikationsnetz 
durch Paketstrome zugefuhrten Verkehrsvo lumens, z.B. durch 
Kontrolle der Ubermi tt lungs kapazitat einzelner Paketstro- 
me . 

15 - Policy Activation (optional) : ggf . fur einen priorisierten 
Paketstrora Resourcen im Kommunikationsnetz fur des sen 0- 
bermittlung reservieren. 

- Priority Management (optional) : Prioritatskennzeichen in 
den Paketen entsprechend der Prioritat ihrer Paketstrome 

20 setzen, kontrollieren und gegebenenf alls korrigieren, 

falls die Pakete bereits mit Prioritaten gekennzeichnet 
sind. 

Der Resource Controller wird auch als 'Policy Decision Point 
25 (PDP) 1 bezeichnet. Er ist beispielsweise innerhalb von sog. 
Edge Routern - auch Edge Device, Zugangsknoten oder bei Zu- 
ordnung zu einem Internet Service Provider '(ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 
konnen auch als Media Gateway zu anderen Netzen ausgebildet 
30 sein, mit denen die Sprach-Daten-Netze verbunden werden. 

Diese Media Gateway sind dann sowohl mit einem Sprach-Daten- 
Netz als mit den anderen Netzen verbunden und dienen intern 
der Umsetzung zwischen den unterschiedlichen Protokollen der 
verschiedenen Netze. Der Resource Controller kann auch nur 
35 als Proxy ausgebildet sein und Resource Controller relevante 
Informationen an eine separate Einrichtung weiterleiten, auf 
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dem der Resource Controller realisiert ist. 

Das prinzipielle Zusammenwirken von Call Controller und Re- 
source Controller gemafi dem Session Initiation Protokoll 
5 (SIP) der IETF bzw. der H.323 Protokoll familie der ITU sei am- 
Beispiel eines Call Setup zwischen zwei als Teilnehmerendge- 
rate ausgebildeten VoIP Einrichtungen erlautert. Dabei wird 
zunachst von einem homogenen Sprach-Daten-Netz ausgegangen. 

10 Innerhalb oder teilweise auch zeitlich vor dem eigentlichen 
Call Setup laufen bei Einwahl eines Endgerats in das IP-Netz 
(z.B. iiber einen Internet Service Provider) die Schritte 
Authentisierung, Autorisierung und (Start des) Accounting ab. 
Diese sogenannte 'AAA' Funktionalitat wird iiblicherweise 

15 durch den Zugriff auf eine Subscriber-Datenbank, in der alle 
Nutzer mit ihren Kennungen, Passwortern, Rechten, etc. ge- 
speichert sind, realisiert. Dieser Zugriff ist langsam und 
vergleichsweise komplex. In den heutigen "Best Effort" IP 
Netzen findet dieser AAA Vorgang normalerweise einmal wahrend 

20 des Einwahlens des Nutzers statt. Eine weitere Authentisie- 
rung erfolgt bei Einsatz eines Call Controllers, wenn sich 
das Endgerat beim Call Controller des Internet Service Provi- 
ders registriert. Nach dem ITU-Standard H.323 wird diese 
Authentisierung bzw. Registrierung eines Endgerats beim zuge- 

25 ordneten Gatekeeper gemafi dem RAS (Registration, Admission, 
Status) Protokoll durchgef uhrt, das im ITU-Standard H. 225.0 
beschrieben ist. 

Der eigentliche Call Setup beginnt iiblicherweise damit, dass 
30 in einem ersten Schritt die Endgerate der Teilnehmer ihre 

Fahigkeiten (z.B. Liste der unterstiitzten CODEC) austauschen, 
um die benotigten Ressourcen (z.B. Bandbreite) und die gefor- 
derte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endgerate 
sind bei Sprachtelephonie z.B. als IP-Telephone ausgebildet, 
35 bei Online-Video ware eines der Endgerate ein Content- bzw. 
Application-Server, z.B. im Netz des ISP. 
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Der Austausch der Signalisierungsnachrichten erfolgt entweder 
direkt zwischen den Endgeraten oder unter Vermittlung eines 
Call Controllers. Hierbei 1st bei jedem Call fur jedes Endge- 
rat und fur jede Ubertragungsrichtung individuell festgelegt, 
5 welche Varlante zum Einsatz koinmt. Die erste Variante wird in 
der H.323 Terminologie auch als 'Direkt Endpoint Call Signal- 
ling' und die zweite als 'Gatekeeper Routed Call Signalling' 
bezeichnet. Bei Direct Endpoint Call Signalling konnen an 
einen Call Controller ggf. Kopien ausgewahlter Signalisie- 
10 rungsnachrichten ubermittelt werden, so dass ein Call- 
Controller auch bei dieser Variante haufig Kenntnis von den 
zwischen den Endgeraten abgestimmten Ressourcen- und QoS- 
Anforderungen hat. Diese Anf orderungen werden jedoch von ihm 
selbst nicht aktiv beeinflusst oder verifiziert. 

15 

In einem zweiten, optionalen Schritt kann die derart abge- 
stiinnite Ressourcen- und QoS-Anf orderung direkt von den Endge- 
raten der Teilnehnter an ihren zugeordneten Resource Control- 
ler ubermittelt werden. Nach Prufung der Ressourcen- und QoS- 
20 Anforderung wird von dem Resource Controller eine Bestatigung 
(oder Ablehnung) an das Endgerat zuriickgeschickt . 

In einem dritten, ebenfalls optionalen Schritt wird im Edge 
Router und gegebenenfalls weiteren Routern im Netz eine Poli- 
25 cy aktiviert, mit der diese Router priifen und gewahrleisten, 
dass der vom Endgerat verursachte Verkehr innerhalb der Gren- 
zen liegt, die in der Anforderung spezifiziert wurden. Ein 
Beispiel fiir einen derartigen Reservierungsmechanismus ist 
RSVP (resource Reservation Protocol) . 

30 

Zur Durchfuhrung der drei Schritte wird eine Mehrzahl von 
Nachrichten versendet, die lediglich zur Abstimmung der be- 
teiligten Komponenten untereinander, jedoch nicht zur tiber- 
mittlung der "eigentlichen Informationen" zwischen den Endge- 
35 raten dienen. Diese mit den Nachrichten ubermittelt en Infor- 
mationen werden iiblicherweise als Signalisierungsinformatio- 
nen, Signalisierungsdaten bzw. schlicht als Signalisierung 
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bezeichnet. Der Begriff ist dabei weit zu verstehen. So sind 
z.B. neben den Signalisierungsnachrichten auch die Nachrich- 
ten gemafi dem RAS Protokoll, die Nachrichten gemafi dem ITU- 
Standard H.24 5 zur Steuerung von Nutzkanalen bestehender 
5 Gesprache sowie alle weiteren ahnlich ausgebildeten Nachrich- 
ten umfasst. Das Signalisierungsprotokoll fur den Verbin- 
dungsaufbau (Call Setup) und -abbau (Call Release) nach der 
ITU ist z.B. im Standard H. 225.0 beschrieben, das nach der 
IETF im RFC 2453bis ("SIP: Session Initiation Protocol"). Die 
10 "eigentlichen Informationen" werden zur Unterscheidung von 

der Signalisierung auch Nutzinf orroationen, Payload, Medienin- 
forroationen, Mediendaten oder schlicht Medien genannt. 

Kommunikationsbeziehungen, die zur tibermittlung der Signali- 
15 sierung dienen, werden im weiteren auch als Signalisierungs- 
verbindungen bezeichnet. Die zur tiberraittlung der Nutzinf or- 
mationen eingesetzten Kommunikationsbeziehungen werden z.B. 
Sprechverbindung, Nutzkanalverbindung oder - vereinfacht - 
Nutzkanal, Bearerchannel oder schlicht Bearer genannt. 

20 

Bei Zusammenschluss eines derartigen konvergenten Sprach- 
Daten-Netzes mit einem konventionellen leitungsorientierten 
Sprachnetz entstehend bei Ubermittlung von Informationen iiber 
die Grenzen der jeweiligen Netze hinweg neue technische Prob- 
25 lemstellungen aufgrund der unterschiedlichen Technologies 
die in den jeweiligen Netztypen zum Einsatz kommen. 

Es ist Aufgabe der Erfindung, zumindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer Losung den 
30 Stand der Technik zu bereichern. 

Die Erfindung stellt sich die Frage, warum es die VoIP Tech- 
nologie es bis heute nicht geschafft hat f sich f lachendeckend 
als Alternative zur konventionellen, leitungsorientierten 
35 Telephonnetzen durchzusetzen . Wahrend sich VoIP innerhalb von 
privaten (Unternehmens-) Netzen schon etablieren konnte, ist 
dies in offentlichen Netzen - auch Public Switched Telephone 
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Network (PSTN) genannt - noch nicht erfolgt. Die fortschrei- 
tende Verbreitung von sogenannten Messenger Applikationen auf 
privat benutzten Rechnern - auch Personal Computer (PC) ge- 
nannt - erlaubt zwar mittlerweile auch den Aufbau von Sprech- 
5 verbindungen von PC zu PC. Telephonate vom PC aus in das 

offentliche Telefonnetz sind aber immer noch nicht weit ver- 
breitet. 

Ein Grund fur diese langsame Verbreitung von VoIP in hybriden 
10 Netzen, die auch ein offentliches Telephonnetz umfassen, 

liegt aus Sicht der Erfindung in der Vergebuhrung . Bei der 
Uberleitung der Verbindung in das PSTN entstehen fur den 
Betreiber des PSTN Kosten, die letztendlich der anrufende 
Teilnehmer tragen muss . Diesen Teilnehmer eindeutig zu iden- 
15 tifizieren und ihm nachtraglich die Kosten fur sein Gesprach 
in Rechnung zu stellen ist jedoch schwierig und wurde bisher 
noch nicht zuf riedenstellend gelost. 

Es ist bekannt, dass sich VoIP Teilnehmer eine Client Soft- 
20 ware auf ihrem PC installieren und sich mit Hilfe dieser 

Software im folgenden auf dem zentralen Kommunikations server 
ihres VoIP Providers (z.B. MSN, Yahoo) registrieren . Da sich 
alle Nutzer einer bestimmten Client Software ublicherweise 
bei dera gleichen zentralen Server registrieren, ist es tech- 
25 nisch vergleichsweise einfach, Kommunikationsbeziehungen 
zwischen alien registrierten Teilnehmern herzustellen. Da 
diese Verbindungen innerhalb des IP Netzes bleiben, fallen 
auch keine Gesprachsgebuhren an, die man den Teilnehmern in 
Rechnung stellen musste. 

30 

Anders verhalt es sich, wenn man mit solch einer Client Soft- 
ware ein Gesprach in das PSTN aufbauen will. Der VoIP Provi- 
der muss in diesem Fall die Verbindung iiber einen Media Gate- 
way zu einem bestimmten PSTN fuhren (routen) . Der Betreiber 
35 des PSTN (PSTN Betreiber) hat dann ublicherweise ein Abrech- 
nungsabkommen mit dem VoIP Provider, um ihm die anfallenden 
Verbindungskosten in Rechnung zu stellen. Der VoIP Provider 
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wird seinerseits das Geld vom Nutzer der Clientsoftware ein- 
f ordern . 

Dieses Verfahren ist zumindest fur zwei der beteiligten Par- 
5 teien mit Nachteilen behaftet: 

- Der PSTN Betreiber muss sein Netz mit einer Vielzahl ver- 
schiedener VoIP Providern zusamraenschlieBen. Weiterhin 
muss er fiir jeden dieser VoIP Betreiber ein individuelles 

10 Abrechnungsverf ahren etablieren. Er kann aber trotzdem die 
VoIP Teilnehmer nicht direkt adressieren, urn z.B. seinen 
Dienst zu bewerben oder direkte Rechnungen zu stellen, da 
er keine verlassliche Moglichkeit der Teilnehmeridentif i- 
zierung hat. 

15 

- Der VoIP Teilnehmer ist bei den PSTN Verbindungen von den 
Konditionen abhangig, die ihm sein VoIP Provider anbietet. 
Dies begrenzt die Flexibilitat der VoIP Teilnehmer, wenn 
der Netzubergang per Media Gateway nur zum PSTN eines oder 

20 weniger PSTN Betreiber realisiert wird. Diese Begrenzung 

wird verstarkt, wenn bei einera weltweit agierenden VoIP 
Provider diese reduzierte Auswahl von PSTN Betreiber in 
vielen Lander besteht. 

25 Eine Losung ftir diese der Erfindung zugrunde liegende Prob- 
lemsituation ist in den Patentanspruchen angegeben. 

Mit dieser Losung sind eine Vielzahl von Vorteilen verbunden: 

30 - Durch die Zuweisung der Teilnehmeridentifikation zu einem 
Server wird die bisherige starre Konf iguration aufgelost, 
bei der die Identitat eines VoIP. Teilnehmers nur seinem 
zugeordneten VoIP Provider bekannt ist. Diese Flexibili- 
sierung ermoglicht andere Konf igurationen, bei denen je 

35 nach deren Ausbildung auch anderen als dem VoIP Provider 

die Identitat des A-Teilnehmers bekannt sein kann. Insbe 
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sondere kann dieser Andere auch ein PSTN Betreiber sein. 

- Durch die Verschiebung des Aufbaus der Signalisierungsver- 
bindung in das PSTN, die bislang im Anschluss an den Ver- 

5 bindungswunsch des A-Teilnehmers vom VoIP Betreiber aus- 
ging, hin zu dem Server wird die Vergebuhrung vom VoIP 
Provider entkoppelt, weil die Vergebuhrung ublicherweise 
demjenigen zugeschrieben wird, der den Aufbau einer Ver- 
bindung initiiert f d.h. vorliegend dera Betreiber des Ser- 
10 ver und nicht mehr dem VoIP Betreiber. 

- Ein PSTN Betreiber kann bei Entkopplung von Server und 
VoIP Betreiber direkt Endkunden fur seinen Dienst gewin- 
nen, ohne auf die Zusammenarbeit mit einem VoIP Provider 

15 angewiesen zu sein. 

- Diese Entkoppelung ermoglicht eine Zentralisierung, bei 
der weniger Server als VoIP Provider vorgesehen sind. In 
diesem Fall reduziert sich die Anzahl der Server, fur die 

20 von den PSTN Betreibern ein individuelles Abrechnungsver- 

fahren etablieren muss, wodurch vorteilhaft eines der von 
der Erfindung erkannten Probleme gelost wird. 

- Im Falle der durch die Erfindung ermoglichten Option einer 
25 Zentralisierung des Servers ist wegen der dann geringeren 

Anzahl von Servern, die ggf . zudem im Wettbewerb zueinan- 
der stehen, eine Anbindung an mehrere PSTN Betreiber zu 
erwarten, weil die Anzahl der Anbindungen sinkt und somit 
leichter handhabbar wird und der Wettbewerb infolge der 
30 dort gebotenen Dif f erenzierung der unterschiedlichen Ser- 

ver die Ausbildung eines breiten Angebots an PSTN Betrei- 
bern fordert. Dies verringert das Problem der VoIP Teil- 
nehmer, in ihrer Auswahl von PSTN Betreibern beschrankt zu 
sein. 

35 
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Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten Anspruchen. 

Bei Ausbildung des Servers als WEB Applikation, d.h. als 
5 Computerprogramm, auf das mit einem beliebigen, zeitgemaBen 
Browser (z.B. Microsoft Interner Explorer, Netscape Communi- 
cator) durch Angabe einer weltweit eindeutigen DRL wahlfrei 
zugegriffen werden kann, wird eine vollstandige Entkopplung 
zwischen dem physikalischen Netzzugang von Teilnehmern und 
10 der Anordnung des Server bewirkt. Dies bedeutet, dass der 

Server prinzipiell an einem beliebigen Ort weltweit positio- 
niert werden kann. 

Bei Erfassung der IP Adresse eines auf die WEB Applikation 
15 zugreifenden Teilnehmers kann diese automatisch den ankommen- 
den IP Paketen entnommen werden, so dass vorteilhaft keine 
manuelle Eingabe der IP Adresse erforderlich ist. In diesem 
Fall ist nur die manuelle Erfassung derjenigen Daten erfor- 
derlich, durch die der gerufene Teilnehmer gekennzeichnet 
20 wird. 

Durch eine Anfrage bei dem Teilnehmer, dessen IP Adresse 
bekannt ist, kann ermittelt werden, welche Client Software 
bei diesem Teilnehmer zur Nutzung von VoIP zum Einsatz kommt. 

25 Dies fuhrt zu dem Vorteil, dass der VoIP Teilnehmer nicht 
mehr, wie heute noch ublich, eine spezielle Client Software 
installieren muss. Der VoIP Teilnehmer muss sich nicht mehr 
auf einen bestimmen VoIP Provider festlegen und dessen Client 
auf seinem PC installieren, wodurch er auf die PSTN Betreiber 

30 festgelegt wird, die mit dem VoIP Provider ein Abrechnungs- 
verfahren etabliert haben. Er kann stattdessen aus einer 
Vielzahl von PSTN Betreibern den fur seine Bedurfnisse geeig- 
netsten heraussuchen und direkt von diesem abgerechnet wer- 
den. 

35 

Durch Bestimmung der Identitat eines Teilnehmers - bspw. 
durch Relationen seiner kennzeichnenden Daten mit einer be 
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stehenden Regis trierungsdatenbank, kann eine unmittelbare 
Vergebiihrung an diesen Teilnehmer mithilfe der in der Regist- 
rierungsdatenbank hinterlegten Daten erfolgen. Dies wird 
vorzugsweise dadurch untersttitzt, dass von dem Server der 
5 Aufbau eines Bearer unterstutzt und dabei die Zeitdauer des 
Bestehens des Bearers durch einen Vergebiihrungsdatensatz 
protokolliert wird. Zur Vermeidung von inkonsistenten Verge- 
biihrungsdatensatzen wird dabei vorzugsweise das Bestehen des 
Bearers mit einem Timer Mechanismus uberwacht, der z.B. als 
10 Watchdog ausgebildet sein kann und von dem Server ausgeht. 

Schone Vorteile geben sich, wenn der Server einem PSTN 
Betreiber zugeordnet wird. Ein PSTN Betreiber kann dann ira 
Idealfall seinen Kunden sogar die anfallenden Gesprachsgebiih- 

15 ren ohne jegliche Registrierung direkt iiber die normale Fern- 
melderechnung abrechnen. Ein Beispiel hierfiir ist ein VoIP 
Teilnehmer, der per T-DSL und T-Online auf erf indungsgeraafien 
VoIP Server der Deutschen Telekom zugreift. Der Server der 
Deutschen Telekom kann dann uber die bei T-Online verwaltete 

20 IP Adresse des VoIP Teilnehmers eindeutig auf das PSTN Fern- 
meldekonto des Teilnehmers schliefien. Eine separate Prozedur 
zur Authentifizierung des Teilnehmers kann entf alien. 

Die Erfindung wird im folgenden anhand von weiteren Ausfiih- 
25 rungsbeispielen, die auch in den Figuren dargestellt sind, 
erlautert. Es zeigt hierbei: 

Figur 1 eine Anordnung zur Durchfuhrung des erfindungsgema- 
Ben Verfahrens mit einem hybriden Koramunikations- 
30 netz f bestehend aus einem paketorientierten Inter- 

net, einem leitungsorientierten PSTN, einem zwi- 
schengeschalteten Media Gateway und Media Gateway 
Controller sowie zwei Endpunkten einer Informati- 
on subermitt lung 

35 

Figur 2 ein Ablauf diagramm, in dem eine Ausfiihrung des 
erf indungsgemafien Verfahrens exemplarisch aufge 
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zeigt ist 

In Figur 1 ist eine beispielhaf te Anordnung zur Durchfiihrung 
des erfindungsgem&Ben Verfahrens dargestellt. Es sei betont, 
5 dass die hierbei aufgezeigten Ausftihrungen dabei trotz ihrer 
teilweise detailgetreuen Darstellung lediglich beispielhaf ter 
Natur und nicht einschrankend zu verstehen sind. Sie umfasst 
ein leitungsorientiertes Kommunikationsnetz PSTN und ein 
paketorientiertes Kommunikationsnetz IN, die durch ein zwi- 

10 schengeschaltetes Media Gateway zur Konvertierung zwischen 
unterschiedlichen, netzspezifischen Nutzkanaltechnologien 
RTP/RTCP (Real Time [Control] Protocol) und TDM (Time Devisi- 
on Multiplex) und einen zwischengeschalteten Media Gateway 
Controller zur Konvertierung zwischen unterschiedlichen netz- 

15 spezifischen Signalisierungsprotokollen SIP (Session Initia- 
tion Protocol) und SS7 (Signalling System No. 7) zu einem 
hybriden Netz zusammengeschlossen sind. Das Gateway MG wird 
dabei von dem Controller MGC durch ein - vorzugsweise inter- 
national genormtes - Protokoll, z.B. MGCP (Media Gateway 

20 Control Protocol) oder H.248 gesteuert. Das Netz IN ist vor- 
zugsweise als das Internet ausgebildet. Fur den einschlagigen 
Fachmann ist dabei of f ensichtlich, dass die Erfindung selbst- 
verstandlich in weiteren paketorientierten Netzen zum Einsatz 
kommen kann wie z.B. Intranet, Extranet, einem lokalen Netz 

25 (Local Area Network - LAN) oder einem, z.B. als Virtuelles 

Privates Netz (VPN) ausgebildeten f irmeninternen Netz (Corpo- 
rate Network) . 

An das Netz IN ist ein Server S angeschlossen, auf den z.B. 

30 mit Hilfe eines IP basierten Protokolls HTTP zugegriffen 

wird. Der Server S umfasst bspw. als Computerprogrammprodukt 
P ausgebildete Applikationen APL, insbesondere WEB Applikati- 
onen, die Softwarecodeabschnitte zur (multi-) prozessorge- 
stiitzten Ausfuhrung des erf indungsgemaflen Verfahrens umfas- 

35 sen. Optional konnen dabei Teile der Computerprograramprodukte 
P auch mit Hilfe von spezieller Hardware (z.B. Signalling- 
Prozessoren) realisiert sein. Dem Server zugeordnet ist eine 



WO 2005/013577 



PCT/EP2004/050688 



15 



Teilnehmerdatenbank zur Identification, Regis trierung und/ 
oder Verification von Teilnehmern und deren Rechten, auf die 
z.B. mit einem entsprechenden Protokoll LDAP (Lightweigth 
Directory Access Protocol) zugegriffen wird. 

5 • 

Ein erster Teilnehmer A ist dem Netz IN, ein zweiter Teilneh- 
mer B dem Netz PSTN zugeordnet. Der Zugriff auf das Netz IN 
wird mit Hilfe einer bekannten IP Anschlusstechnik (z.B. IP 
over xDSL, gesteuert durch das Protokoll PPP und verraittelt 
10 durch einen zwischengeschalteten ISP zur dynamischen Vergabe 
von IP Adressen fur die - meist zeitlich begrenzte - eindeu- 
tige Adressierung des Teilnehmers A im Netz IP) , der auf das 
Netz PSTN mit Hilfe einer bekannten TDM Anschlusstechnik 
(z.B. ISDN, gesteuert durch das Protokoll DSS1) bewirkt. 

15 

In Figur 2 ist eine Ausfiihrung des erf indungsgemafien Verfah- 
• rens am Beispiel eines exemplarischen, zeitlichen Verlauf s 
eines Gesprachs CALL zwischen den beiden Teilnehmern A, B rait 
Hilfe eines Ablaufdiagramms dargestellt. In dem Diagramm sind 

20 standardisierte (Signalisierungs-) Nachrichten SIP: INVITE, 
100 TRYING, 180 RINGING, 200 OK, SIP:ACK und SIP: BYE zum 
Austausch von Signalisierungsdaten zwischen dem Teilnehmer A, 
dem Server S und dem Controller MGC aufgezeigt. Diese Nach- 
richten sind dem standardisierten Protokoll SIP entnommen, 

25 das bei der IETF fur die Steuerung von Verbindungen RTP zwi- 
schen Endpunkten einer RTP Verbindung entwickelt wurde. Im 
vorliegenden beispielhaften Ablauf diagramm sind diese End- 
punkte als Teilnehmer A und Gateway MG ausgebildet. Fur den 
Fachmann ist of f ensichtlich, dass andere Signalisierungspro- 

30 tokolle, z.B. die der Protokollf amilie H.323, mit gleicher 
Wirkung eingesetzt werden konnen. 

Als weiteres Ausfuhrungsbeispiel der Erfindung wird ein Zu- 
sammenwirken des VoIP Teilnehmers A (bzw. dessen VoIP Clients 
35 C) , des Servers B, des Controllers MGC, des Gateways MG End- 
punkts A und des PSTN Teilnehmers B (bzw. dessen Telephon T) 
ausgefuhrt, bei dem es einem PSTN Betreiber ermoglicht wird, 
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Verbindungen von VoIP Teilnehmern zu PSTN Teilnehmern seines 
Netzes anzubieten und den initiierenden VoIP Anrufer direkt 
zu vergebiihren. Die dem Beispiel zugrunde liegende Netzkonfi- 
guration ist dabei Figur 1 abgebildet, wobei folgende Zuord- 
5 nungen angenommen werden: 

Komponenten des PSTN Betreibers: 

- Das leitungsorientierte Netz PSTN 

- Der Media Gateway Controller MGC - hier auch IP-PSTN Gate- 
10 way genannt (z.B. ein hiQ9200 der Firma Siemens) 

- Mindestens ein Media Gateway MG (z.B. ein hiG1200 der 
Firma Siemens) 

Komponenten, auf die der VoIP Teilnehmer A seinen Zugang zum 
15 Netz IN stutzt: 

- Eine bestehende Onlineverbindung uber (s)einen Internet- 
provider ISP zum paketorientierten Internet IN 

- Einen beliebigen Web-Browser (z.B. einen Internet Explorer 
der Firma Microsoft) 

20 - Einen beliebigen, installierten VoIP Client C (z.B. einen 
SIP Sigma Client der Firma Siemens) 

Weiterhin kommt im diesem Ausfiihrungsbeispiel ein erfindungs- 
gema&er WEB und/oder Applikation Server S zum Einsatz, der 
25 vorzugsweise dem PSTN Betreiber zugeordnet ist. 

Im beschriebenen Szenario kommuniziert der Server S sowohl 
mit dem IP-PSTN Gateway MGC als auch mit dem VoIP Client C 
des Teilnehmers A uber das standardisierte SIP Protokoll 
30 (Session Initiation Protocol) . Das beschriebene Verfahren ist 
aber grundsatzlich auch bei Verwendung anderer Signalisie- 
rungsprotokolle moglich, z.B. mittels des H.323 Protokolls. 

Die Realisierung des Server S umfasst einen Webserver zur 
35 Unterstutzung des Protokolls HTTP und einen Applicationserver 
zur Durchfuhrung des erfindungsgemaBen Verfahrens. Der Server 
S ist beispielsweise als ein einziger physikalischer Server 
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(genannt Web /Application Server) ausgebildet. Beide Komponen- 
ten konnten genau so gut auf unterschiedlichen, miteinander 
vernetzten Servern liegen. 

5 Um eine Verbindung zum PSTN Teilnehmer B aufzubauen, geht der 
VoIP Teilnehmer A zum Zeitpunkt START mit seinem Browser 
durch Angabe einer bestimmten URL auf eine Webseite des 
Betreibers des Servers, durch die eine graphische Oberflache 
der Applikation APL realisiert wird. Vom Server S wird dar- 
10 aufhin optional eine Authentif izierung des Teilnehmers A 
durchgef iihrt . Hierfiir gibt es mehrere Moglichkeiten: 

- Der Teilnehmer A registriert sich einmalig beim Server S 
und meldet sich dann bei jedera weiteren Zugriff auf den 

15 Server S mit Usernamen und Passwort an. 

- Die Teilnehmeridentif izierung erfolgt automatisch, z.B. 
anhand der IP Adresse des Teilnehmers A. Die IP Adresse 
des Teilnehmers kann der Server S bspw. anhand der von dera 

20 Teilnehmer A empfangenen HTTP Nachrichten erkennen, in de- 

nen iiblicherweise dessen IP Adresse als Kennzeichnung der 
Quelle der Nachricht enthalten ist. Diese Autoraatisierung 
ist beispielsweise dann moglich, wenn der PSTN Betreiber 
mit dem ISP des VoIP Teilnehmers A identisch ist oder mit 

25 diesem kooperiert. 

Im Anschluss konnen von dem Server S optional die technischen 
Moglichkeiten bzgl. der Erreichbarkeit des VoIP Teilnehmers A 
ermittelt werden um herauszufinden, ob - und wenn ja - wie 
30 der VoIP Client angerufen werden kann. Auch hierfiir gibt es 
mehrere Moglichkeiten: 

- Der Teilnehmer A gibt seine SIP Adresse in einem Formular 
ein und der Web/Application Server S speichert diese Daten 

35 in einem Profil dieses Teilnehmers A ab, das in der Teil- 

nehmerdatenbank hinterlegt ist. 
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- Der Web /Application Server S fuhrt eine autoraatische 
Client-Erkennung durch. Er kann dazu beispielsweise eine 
SIP:0PTI0NS Nachricht an den Port 5060 des Teilnehmer-PC s 
senden und aus einer empfangenen Antwort erkennen, ob und 
5 wenn ja, was fur ein Client C auf dem PC des VoIP Teilneh- 

mers A installiert ist. Wenn kein Client installiert bzw. 
instantiiert ist, kann keine Signalisierungsverbindung 
SIP [A] aufgebaut werden. Die Art des Client kann dazu 
verwendet werden, den Ablauf nach Figur 2 entsprechend auf 
10 die spezifischen Eigenarten des Clients C anzupassen, z.B. 

durch eine alternative Ubermittlung von Daten SDP. 

Daraufhin tragt der VoIP-Teilnehmer A in seinem Browser in 
ein Fommlar die Rufnummer des gewiinschten PSTN Teilnehmers B 

15 ein. Alternativ kann der PSTN Betreiber auch einen Telefon- 
buchdienst anbieten, mit dessen Hilfe ein einfacher Click auf 
einen bestimraen Eintrag zum Aufbau der Verbindung zwischen 
den beiden Teilnehmern A, B fuhrt. Der Web/Application Server 
S bestimmt aus dieser Adressinf ormation das zustandige IP- 

20 PSTN Gateway MGC. 

Der folgende Schritt zeigt einen deutlichen Unterschied zu 
bisherigen VoIP Verbindungen : Wahrend normalerweise der A- 
Teilnehmer (bzw. sein zugeordneter VoIP Betreiber) eine 

25 (Signalisierungs-) Verbindung zu einem B-Teilnehmer aufbaut, 
initiiert im hier beschriebenen Szenarium der Web/Appli cation 
Server S zwei separate Signalisierungsverbindungen, eine 
erste SIP [A] zum VoIP Teilnehmer und eine zweite SIP [B] , 
SS7, DSS1 zum Teilnehmer B und schaltet diese anschliefiend zu 

30 einer durchgangigen Signalisierungsverbindung SIP, SS7, DSS1 
zusammen. 

Dabei wird infolge des hybriden Netzszenarios das Protokoll 
der zweiten Signalisierungsverbindung SIP [B] , SS7, DSS1 
35 mehrfach in bekannter Weise umgesetzt, und zwar das Protokoll 
SIP [B] , das zwischen dem Server und dem IP-PSTN Gateway MGC 
zum Einsatz kornmt, von dem IP-PSTN Gateway MGC auf das Proto 
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koll SS7 des Netzes PSTN und letzteres dann vom Vermittlungs- 
knoten STP {Signalling Transfer Point) auf das Protokoll DSS1 
des Teilnehmeranschlusses . Diese Umsetzungen bleiben fur den 
Server S verborgen, so dass die zweite Signalisierungsverbin- 
5 dung SIP [B] , SS7 , DSS1 virtuell zwischen dem Server S und 
dem Teilnehmer B besteht. Das IP-PSTN Gateway MGC wirkt, rait 
anderen Worten gesagt, gegemiber dem Server S als Proxy des 
Teilnehmers B. 



10 Neben dem Aufbau einer durchgangigen Signalisierungsverbin- 
dung SIP, SS7, DSS1 ist die Durchschaltung einer Nutzkanal- 
verbindung / Bearers RTP, TDM zwischen den Teilnehmern A und 
B erforderlich. Diese setzt sich in diesem Beispiel aus einen 
paketorientierten Bearer RTP im Netz IN und einem leitungs- 

15 orientierten Bearer TDM im Netz PSTN zusaramen. Die Endpunkte 
des Bearers RTP im Netz IN sind dabei das Media Gateway MG 
sowie der VoIP Client C des Teilnehmers A, die des Bearers 
TDM im Netz PSTN das Media Gateway MG sowie das konventionel- 
le Telephon T des Teilnehmers B. 

20 

Der Web/ Application Server S unterstutzt dabei den gegensei- 
tigen Austausch von Inf ormationen, die fur den Aufbau des 
paketorientierten Bearers RTP benotigt werden. Dieser Aus- 
tausch erfolgt z.B. rait Hilfe des Protokolls SDP (Session 

25 Description Protocol), welches Bestandteil von SIP ist. Dabei 
ergeben sich besonders schone Vorteile, wenn der Standardab- 
lauf gemafi dem Offer-Answer Modell von SIP erhalten bleibt. 
Dieser Standardablauf sieht vor, dass auf der Seite des ru- 
fenden Teilnehmers in die Nachricht SIP: INVITE ein Datensatz 

30 SDP einfiigt wird, der u.a. auch eine Liste aller CODEC ent- 
halt, die auf der Seite des rufenden Teilnehmers unterstutzt 
werden (= Offer) , und dass auf der Seite des gerufenen Teil- 
nehmers in die Nachricht 200 OK ein Datensatz SDP eingefugt 
wird, in dem der fur das folgende Gesprach CALL zu verwenden- 

35 de CODEC angezeigt wird (= Answer) . Diese Unterstutzung ist 
im Ablaufdiagramm von Figur 2 naher erlautert: 
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Zunachst wird vora Server S eine Nachricht SIP:INVTTE zum IP- 
PSTN Gateway MGC gesendet. Diese Nachricht konnte zwar schon 
die IP Adresse des Clients C enthalten, weil diese schon mit 
Zugang der ersten HTTP Nachricht bekannt ist. Es fehlen je- 
5 doch zu dies em Zeitpunkt fur einen erfolgreichen Aufbau des 
Bearers RTP zumindest noch die Angabe des Ports des Clients C 
sowie die Liste der CODEC, die von dem Client C unterstiitzt 
werden, so dass die Nachricht SIP: INVITE keinen bzw. zumin- 
dest keinen vollstandigen SDP Datensatz enthalt. 

10 

Von dem IP-PSTN Gateway MGC wird daraufhin dem Server S mit 
einer Nachricht 100 TRYING angezeigt, dass versucht wird, den 
Teilnehmer B zu erreichen, und der bekannte Aufbau des Bea- 
rers TDM im Netz PSTN durchgef iihrt . In diesem Zusammenhang 

15 werden im Media Gateway MG ein in das Netz PSTN fuhrender 
PSTN Port und ein in das Netz IP fuhrender RTP Port belegt. 
Die Signalisierung zwischen dem IP-PSTN Gateway MGC und dem 
Teilnehmer B gemafi dem Protokoll SS7 - dort insb. dem Proto- 
koll ISUP - und dem Protokoll DSS1 ist Stand der Technik und 

20 wird hier nicht naher beschrieben. Das gleiche gilt fur die 
Signalisierung zwischen dem IP-PSTN Gateway MGC und dem Media 
Gateway MG mit den Protokollen MGCP bzw. H.248. 

Nach erfolgreichem Aufbau des Bearers TDM wird im Netz PSTN 
25 der Klingelton angelegt und im Bearer TDM bis zum Media Gate- 
way MG ubermittelt. Vom IP-PSTN Gateway MGC wird die Nach- 
richt 180 RINGING an den Server gesendet, in der ein voll- 
standiger Datensatz SDP [MG] enthalten ist, insbesondere der 
RTP Port im Gateway MG sowie die Liste der von dem RTP Port 
30 des Media Gateway MG unterstiitzten CODEC. 

Der Datensatz SDP [MG] wird von Server S dazu verwendet, urn 
eine Nachricht SIP : INVITE zu erzeugen, die einen vollstandi- 
gen Datensatz SDP im Sinne einer Offer enthalt. Diese Nach- 
35 richt SIP: INVITE (SDP [MG] ) wird an den Teilnehmer A gesen- 
det. Mit anderen Worten: Die Nachricht SIP: INVITE in Richtung 
des Teilnehmers A wird in diesem Ausfuhrungsbeispiel solange 



WO 2005/013577 



PCI7EP2004/050688 



21 

verzogert, bis der Datensatz SDP [MG des] Media Gateways MG 
vom Server S erapfangen wird. Dieser Ablauf konnte nach dem 
Of fer/Answer-Modell von SIP selbstverstandlich auch variiert 
werden. Der hier beschriebene Ablauf resultiert aber in Rich- 
5 tung des Clients C in dem oben beschriebenen Standardablauf . 
Darait ist der besonders schone Vorteil verbunden, dass dieser 
Ablauf von alien SIP Clients C unterstutzt werden sollte. 

Nach Empfang der Nachricht SIP: INVITE beginnt der VoIP Client 
10 C des Teilnehmers mit der Anzeige des eingehenden Anrufs. 

Dies wird dem Server mit den iiblichen Nachrichten 100 TRYING 
und 180 RINGING angezeigt. Sobald der Teilnehmer A den Ruf 
annimmt, wird an den Server S eine Nachricht 200 OK gesendet. 
Spatestens in diese Nachricht wird ein Datensatz SDP [A] 
15 eingefugt, mit dem u.a. der Port des VoIP Clients C und der 
ausgewahlte CODEC angezeigt wird. Der Bearer RTP kann bereits 
unidirektional vom Client C in Richtung des Media Gateways MG 
in Betrieb genommen werden. 

20 Fur eine Aktivierung der Gegen richtung vom Media Gateway MG 
zu Client C ist noch erforderlich, den Datensatz SDP [A] an 
den Media Gateway MG weiterzuleiten. Sobald diese Daten vom 
Server S an den Media Gateway MGC weitergeleitet sind, kann 
der Bearer RTP bi-direktional in Betrieb genommen werden. Die 

25 Teilnehmer A und B konnen dann miteinander sprechen. 

Eine Moglichkeit zur Weiterleitung der Daten SDP [A] besteht 
darin, sie dem IP-PSTN Gateway mit der Nachricht SIP:ACK 
mitzuteilen, die als Bestatigung der Nachricht 200 OK uber- 
30 mittelt wird, mit der angezeigt wird, dass der Teilnehmer B 
den eingegangen Ruf angenommen hat. 

Eine weitere Moglichkeit besteht darin, die Daten SDP [A] 
unmittelbar nach deren Empfang mit einer gesonderten Nach- 
35 richt SIP:xxx weiterzuleiten. Dies hat den Vorteil, dass mit 
Empfang der Daten SDP [A] der RTP Port des Media Gateway MG 
aktiviert und der bereits aus dem Netz PSTN anliegende Rufton 
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bis zura Abheben des Zielteilnehmers B als auch T6ne oder 
Ansagen (Besetzt, Fehlerfalle, usw.) an den Client C ubermit- 
telt werden konnen. 

5 Die Nachricht SIP:xxx kann als Nachricht SIP: UPDATE ausgebil- 
det sein. Dies stellt zwar einen bewussten Verstofi gegen das 
Offer-Answer Modell dar, weil die Nachricht SIP: UPDATE grund- 
satzlich eine neue Offer dar stellt. Diese kann jedoch durch 
eine entsprechende Anpassung des IP-PSTN Gateway MGC kompen- 
10 siert werden. 

Alternativ kann die Nachricht SIP:xxx als Nachricht SIP:PRACK 
ausgebildet sein. Zur Unterstiitzung dieser Alternative wird 
dabei in der vorausgegangen Nachricht SIP: INVITE dem IP-PSTN 

15 Gateway MGC angezeigt, das "reliable provisional responses" 
unterstutzt wird. In diesem Fall ubermittelt das IP-PSTN 
Gateway MGC die Daten SDP [MG] schon in der Nachricht 180 
RINGING und erwartet daraufhin die Nachricht SIP:PRACK als 
Bestatigung. In diese Bestatigung werden dann die von Teil- 

20 nehmer A empfangenen Daten SDP [A] eingefiigt. Dabei wird das 
Senden der Nachricht SIP:PRACK vora Server S so lange verzo- 
gert, bis die Nachricht 200 OK vora Teilnehmer A empfangen 
wurde. 

25 Als Variante konnen die Daten SDP [A] unabhangig von der 

Obermittlung mit einer gesonderten Nachricht SIP:xxx in jedem 
Fall rait der Nachricht SIP:ACK (SDP [A]) Ubermittelt werden. 
Somit werden von dem Server S auch Media Gateways MG unter- 
stutzt/ deren zugehoriges IP-PSTN Gateway MGC den Empfang 

30 einer gesonderten Nachricht SIP:xxx nicht unterstiitzt. 

Fiir den Fall, dass der Teilnehmer B abhebt, bevor der Teil- 
nehmer A den an ihn ergangenen Ruf annimmt, kann bspw. iiber 
ein Bearer Redirection Verfahren eine Ansage fiir den Teilneh- 
35 mer B angelegt werden, dass es sich urn einen VoIP Call han- 
delt und der Teilnehmer B einen Augenblick bis zum Zustande 
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kommen der Verbindung warten rooge. 

Sobald der Web/ Application Server S beide Nachrichten 200 OK 
auf die ausgesendeten Nachrichten SIP: INVITE empfangen hat, 
5 beginnt er mit der Vergebiihrung des Gesprachs CALL. Die Ver- 
gebuhrung endet, sobald der Web/ Application Server eine Nach- 
richt SIP: BYE von einem der beteiligten Endpunkte empfangt. 
Dabei wird z.B. ein abschlieilender Datensat2 fur die Verge- 
biihrung geschrieben. 

10 

Gemaft einer weiteren Ausfiihrung der Erfindung wird in zykli- 
schen Abstanden das Bestehen des Bearers RTP uberpruft. Vor- 
teilhaft kann so bei einem Absturz der Client Software C die 
Vergebiihrung beendet werden. Das Protokoll SIP enthalt zu 
15 diesem Zweck einen Session Timer Mechanismus, welcher hier 
beispielsweise zur Anwendung kommen konnte. 

AbschlieJSend sei betont, dass die Beschreibung der fiir die 
Erfindung relevant en Komponenten des Kommunikationsnetzes 

20 grundsatzlich nicht einschrankend zu verstehen ist. Fiir einen 
einschlagigen Fachmann ist insbesondere of fensichtlich, dass 
Begriffe wie Applikation, Client, Server, Gateway, Control- 
ler, etc... funktional und nicht physikalisch zu verstehen 
sind. Somit konnen beispielsweise die Endpunkte A, B auch 

25 teilweise oder vollstandig in Software und/oder iiber mehrere 
physikalische Einrichtungen verteilt realisiert werden. 
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Patent an spriiche 

1. Verfahren zur Verbindung von Teilnehmern mit zumindest 
5 eihem Kommunikationsnetz, urafassend folgende Schritte: 

. - Erfassung von einen ersten Teilnehmer (A) und einen zwei- 
ten Teilnehmer (B) kennzeichnenden Daten durch einen Ser- 
ver (S), 

. - Aufbau einer ersten Signalisierungsverbindung (SIP [A] ) 
10 zwischen dem Server und dem ersten Teilnehmer und einer 
zweiten Signalisierungsverbindung (SIP [B] , SSI, DSS1) 
zwischen dem Server und dem zweiten Teilnehmer unter Be- 
riicksichtigung der Daten, 
- Zusammenfuhren der beiden Signalisierungsverbindungen zu 
15 einer durchgangigen Signalisierungsverbindung (SIP, SS7, 

DSS1) zwischen den beiden Teilnehmern. 

2. Verfahren nach Anspruch 1, 

bei dem der Server als WEB Applikation (APL) ausgebildet 
20 ist, auf die insbesondere iiber ein Internet (IN) und/oder ein 
IP basiertes Protokoll (HTTP) zugegriffen wird. 

3. Verfahren nach dem vorstehenden Anspruch, 

bei dem als kennzeichnendes Datum die IP Adresse erfasst 
25 wird, mit der auf die WEB Applikation zugegriffen wird. 

4. Verfahren nach dem vorstehenden Anspruch, 

bei dem im Fall eines Zugriffs rait Hilfe einer mit der IP 
Adresse - insbesondere mit Port 5060 - adressierten Anfrage 
30 festgestellt wird, mit welcher Software der auf den Server 
zugreifende Teilnehmer Informationen in das Kommunikations- 
netz ubermittelt. 
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5. Verfahren nach einem der vorstehenden Anspruche, 

bei dem die I dent i tat von auf den Server zugreifenden Teil- 
nehmern unter Berucksichtigung der erfassten Daten bestimrot 
wird. 

5 

6. Verfahren nach dem vorstehenden Anspruch, 

bei dem zur Bestimmung der Identitat des Teilnehmers eine 
erstmalige Regis trierung vorgenommen wird, bei der die Iden- 
titat eindeutig kennzeichnende paten erfasst werden. 

10 

7. Verfahren nach einem der vorstehenden Anspruche, 

bei dem von dem Server der Austausch von Inf ormationen unter- 
stutzt wird, die fur die Einrichtung eines Bearers (RTP, TDM) 
zwischen den Teilnehmern erforderlich sind. 

15 

8 . Verfahren nach dem vorstehenden Anspruch, 

bei dem das Bestehen des Bearers von dem Server - vorzugswei- 
se durch Einsatz eines Timer Mechanismus - uberpriift wird. 

20 9. Verfahren nach einem der beiden vorstehenden Anspruche, 
bei dem von dem Server zumindest ein Vergebuhrungsdatensatz 
protokolliert wird, aus dem zumindest die Zeitdauer des Be- 
stehens des Bearers abgeleitet werden kann. 

25 10. Verfahren nach einem der vorstehenden Anspriiche, 

bei dem der Server einem PSTN Betreiber zugeordnet ist. 

11. Verfahren nach den beiden vorstehenden Ansprilchen, 
bei dem die Vergebuhrung fur diejenigen Teilnehmer, die dem 
30 PSTN des Betreibers zugeordnet sind, iiber die Fernmelderech- 
nung des PSTN Betreibers erfolgt. 



WO 2005/013577 PCT/EP2004/050688 



26 

12. Compute rprogrammprodukt (P) - insbesondere VoIP Client 
oder WEB Applikation (APL) - umfassend Softwarecodeabschnit- 
te, mit denen ein Verfahren nach einem der vorstehenden Ver- 
fahrensanspruche durch zumindest einen Prozessor ausgefiahrt 

5 wird. 

13. Vorrichtung - insbesondere WEB oder Applikation Server 
(S) - umfassend Mittel zur Durchfiihrung eines Verfahrens nach 
einem der vorstehenden Verf ahrens an sp ruche. 

10 

14. Anordnung - insbesondere hybrides Kommunikationsnetz (IN, 
PSTN, MG, MGC) - umfassend die zur Durchfiihrung eines Verfah- 
rens nach einem der vorstehenden Verf ahrensanspruche erfor- 
derlichen Computerprogrammprodukte und/oder Vorrichtungen . 



15 
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